home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group97a.txt / 000075_icon-group-sender _Thu Mar 6 11:24:38 1997.msg < prev    next >
Internet Message Format  |  2000-09-20  |  4KB
  1. Received: by cheltenham.cs.arizona.edu; Sun, 9 Mar 1997 06:28:54 MST
  2. To: icon-group@cs.arizona.edu
  3. Date: Thu, 06 Mar 1997 11:24:38 -0700
  4. From: Alan Watson <alan@oldp.nmsu.edu>
  5. Message-Id: <331F0BE6.819@oldp.nmsu.edu>
  6. Organization: New Mexico State University
  7. Sender: icon-group-request@cs.arizona.edu
  8. Subject: More General Events In Icon
  9. Errors-To: icon-group-errors@cs.arizona.edu
  10. Status: RO
  11. Content-Length: 3429
  12.  
  13. I'm new to Icon. I came to it as something to add to the two tools I
  14. have for solving problems: C on one hand and contortions with awk,
  15. sed, m4, and other shell tools on the other. Until recently I was
  16. singularly impressed and very optimistic, but I've come across what
  17. appears to be a fundamental problem and it's making me think again.
  18. I'd be very grateful if someone more experienced with Icon than I
  19. could comment on this.
  20.  
  21.                         --------
  22.  
  23. A number of applications require responses to events. These events are
  24. commonly: a mouse or keyboard action in a window (graphics events);
  25. the passage of a certain amount of time (alarm events); and the
  26. presense of data ready to be read from a file (input events).
  27.  
  28. Icon provides a general means to respond to graphics events in
  29. isolation (using Event(), Pending(), and Active()) and limited means
  30. to respond to alarm events in isolation (wait for a single alarm with
  31. delay() and WDelay()), and very limited means to respond to input
  32. events (poll stdin with kbhit() or wait for input from a single file
  33. with read() or reads()). However, it provides no means to respond to
  34. combinations of these events.
  35.  
  36.                         --------
  37.  
  38. Do combinations occur in practice? I think they do:
  39.  
  40. (a) As my very first exercise in learning Icon's graphics facilities,
  41. I wrote a clock. My first attempt was:
  42.  
  43.     link graphics
  44.     procedure main()
  45.         WOpen("lines=1","columns=5") | stop("can't open window");
  46.         repeat {
  47.             GotoRC(1,1);
  48.             WWrites(&clock[1:6]);
  49.             WFlush();
  50.             delay(10*1000);
  51.         }
  52.     end
  53.  
  54. The problem with this is that the window is not implicitly refreshed
  55. as required (e.g., when it is exposed by the window manager).
  56. Replacing the WFlush() and delay() with WDelay() does not help.
  57. Instead, the program need to call Event():
  58.  
  59.     link graphics
  60.     procedure main()
  61.         WOpen("lines=1","columns=5") | stop("can't open window");
  62.         repeat {
  63.             GotoRC(1,1);
  64.             WWrites(&clock[1:6]);
  65.             Event();
  66.         }
  67.     end
  68.  
  69. The window is now implicitly refreshed as required. Unfortunately, the
  70. clock only tells the right time once each day. To get this to work
  71. properly, I need to combine graphics events with alarm events.
  72.  
  73. (b) An application I use on a regular basis for image processing
  74. combines a command line interface with a graphics browser. The requires
  75. responding to both graphics events and input events. (Re-writing xterm
  76. within the application would not be acceptable!)
  77.  
  78. (c) A guy down the corridor is implementing the user interface to a
  79. telescope control system. The telescope is controlled by a networked
  80. PC. The user interface runs on a (remote) UNIX work station. The user
  81. interface and the PC communicate by writing and reading NFS files. The
  82. user interface also has a command line interface and a graphical
  83. display. The program must respond to all three kinds of events: it
  84. handles graphical and input events as expected, but in addition must
  85. check for a NFS file every half second or so.
  86.  
  87.                         --------
  88.  
  89. Throwing everything into a language is probably not a good idea.
  90. Therefore, we should not expect one language to be able to do
  91. everything. However, the unsuitability of Icon to these three
  92. applications astonished me; they seemed at first glance well within
  93. the domain of problems it is intended to solve.
  94.  
  95. Am I missing something?
  96.  
  97. Alan
  98.